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(54) Abstract Title: User interface for customising an electronic product 


(57) A system for customising an electronic product 
such as a mobile telephone (200 fig 2) 
comprises a customer requirements capture tool 
(210 fig 2) arranged to receive a customer's 
requirements electronically and display a 
plurality of customisation options to a customer; 
and a back-end processing function, operably 
coupled to the customer requirements capture 
tool (210 fig 2). The back-end processing 
function is arranged to control the plurality of 
customisation options displayed to the customer 
and process inputs entered onto the customer 
requirements capture tool (210 fig 2). The 
back-end processing function captures one or 
more digital resources selected by the customer 
and, in response thereto, arranges the customer 
requirements capture tool (210 fig 2) to display 
said one or more digital resources to the 
customer in enabling the customer to customise 
the electronic product. 
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User Interface for customising an electronic product 

Field of the Invention 

5 This invention relates to providing a customer of an 
electronic product with the ability to completely specify 
their requirements for the design, construction and delivery 
of the product. This invention is applicable to, but not 
limited to, providing a manufacturer' s user interface to 
10 support such customisation. 

Background of Invention - 

In the field of this invention it is known for manufacturers 
15 and the like to attain a business advantage by being able to 
produce (in both mass and small volume down to single unit) 
products to the specific requirements of a customer. For 
example, for a mobile phone manufacturer it is desirable to 
produce a customised product for supply to a mobile phone 
20 operator, distributor or individual end user. 

FIG. 1 illustrates a known a simplified manufacturer/supplier 
process 100 for producing a product build based on received 
customer requirements . 

25 

The process 100 starts with the customer, for example a mobile 
phone network operator, determining what their requirements 
are, in step 110. In a second step 120, the customer passes 
their requirements to the manufacturer/supplier, for example a 
30 mobile phone handset manufacturer. 
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The requirements may include, by way of example only, software 
and application requirements, colour and other hardware 
requirements, billing and delivery requirements, etc. 

5 

The requirements received from the customer are collated and 
interpreted in step 130 by, for example, a sales 
representative from a local organisation of the manufacturer 
or supplier. 

10 

Once the sales representative has collated and interpreted the 
customer requirements, the interpreted requirements are 
typically passed to an order desk, as shown in step 140. 

15 On receiving the interpreted requirements, the order desk 
formalises the requirements, in step 150. That is to say, the 
interpreted requirements are entered into, for example, a 
standard format of the manufacturer's/supplier's internal 
process flows such as a manufacturing line, billing and 

20 delivery system, etc. 

Having formalised the requirements in step 150, the order desk 
passes the formalised requirements to the relevant 
manufacturing/development departments, as shown in step 160. 

25 

Next, in step 170, the manufacturing/development departments 
implement the hardware and software requirements, and create a 
Bill of Materials (BOM) for the customised product and samples 
of the customised product. 


30 
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In step 180, the samples are checked to ensure that they 
fulfil the formalised requirements. 

Finally, once the samples have been checked that they fulfil 
5 the formalised requirements, the customised product is built 
and shipped to the customer 190. 

However, this known prior art has the following disadvantages . 

10 It is often the case that the customer requirements are not 
passed to the sales representative, in step 120, in a single, 
comprehensive fashion. Rather, the requirements may be 
provided over a period of time, for example via a product 
specification containing the basic requirements, followed by 

15 subsequent phone calls, emails, etc providing further 

requirements or refinements of the order /enquiry . 

This provides the problem that it is necessary for the sales 
representative to collate all the information received and to 
20 try to make sense of the information which may conflict. 
Furthermore, it will be necessary for the sales representative 
to interpret the requirements, thus adding certain 
subjectivity and human error to the capturing of customer 
requirements . 

25 

Furthermore, there is an inherent delay in the process, whilst 
waiting to receive all the requirements from the customer, in 
addition to the time it takes the sales representative to 
collate and interpret the requirements. 


30 
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The above problems are further compounded at the order desk. 
The interpreted requirements received by the order desk, which 
as mentioned above are prone to subjectivity and human error, 
must be formalised. This requires the requirements to be 
5 converted into a suitable format of the manufacturer's 
internal process flow. 

The interpreted requirements received by the order desk are 
likely to be in a format that is a mixtures of formats in 
10 which the requirements were received from the customer and 
that used by the particular sales representative. Therefore, 
it is possible that this differs significantly to that of the 
internal process flow. 

15 As a consequence of this, when entering the requirements into 
the format of the internal process flow, the individual 
entering the requirements will need to further interpret those 
requirements in order to best express them in the new format. 
Consequently further subjectivity and human error is 

20 introduced. 

Once again, the need to formalise the requirements adds delay 
to the process. This delay is further increased since it will 
be necessary to carry out financial checks, etc. to ensure 
25 that the customer has a sufficiently high credit rating and/or 
has not been "black listed" due to non-payment of invoices, 
etc. in the past. 

It is also necessary to ensure that the requirements received 
30 are viable. For example, that all software and hardware 


- 5 - 


components are available and supported by the 
manufacturer/supplier, and that the specific combination (s) of 
components is/are valid and without conflict. This viability 
check adds yet more delay to the process. 

5 

As will be appreciated by a skilled artisan, the subjectivity 
used in interpretation of the requirements at both stages 
mentioned above can lead to the formalised requirements 
varying from the original customer requirements. Furthermore, 
10 human error can lead to incorrect values, etc. occurring in 
the formalised requirements. 

The outcome of this is that at the validation stage (step 
180), the samples, etc. are checked against the formalised 
15 requirements. Consequently, even if samples meet the 
formalised requirements, there is a significant possibility 
that they would not meet the original customer requirements, 
due to the subjectivity and human error introduced in the 
process . 

20 

Yet more delay occurs during the process due to the 
implementation of the requirements. This is generally done on 
an individual basis manually by, in the case of software, 
manually creating a customised software build. This is then 
25 manually tested during validation, which again increases the 
delay. 

A further problem that is encountered with this known process 
is that a customer may have digital resources, for example 
30 graphics, (e.g. bitmap files) or audio files, which they 
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require to be included as a part of the customised product. 
Such digital resources are not conducive to being captured on 
paper, and are, in general, required in an appropriate digital 
format. The known process described above does not allow for a 
5 reliable means for such digital resources to be managed. 

In particular, a customer may specify that certain digital 
resources are desired early on, but the digital resources may 
not be provided in a suitable format until much later. This 

10 can lead to further delays etc., which are out of the control 
of the manufacturer. Furthermore, even when digital resources 
are provided in an appropriate format, the known process is 
not conducive for direct association of specific resources to 
specific orders. Thus, there is a risk of digital resource 

15 files being mislaid or associated to the wrong orders. 

This known process also has the disadvantage that it is 
relatively inefficient in terms of both time and resources, as 
explained below. 

20 

From the point of view of the manufacturer's resources, i.e. 
actual people required to perform tasks, etc., Table 1 below 
illustrates the typically required resources for a mass 
produced product manufactured by a small to medium sized 
25 enterprise. 


Area 

Task 

Resources 

Sales 

Representative 

Collating and interpreting 
customer requirements 

1 

Order desk 

Formalising interpreted 

1-2 
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requirements 


Manufacturing/ 
Development 

Implementing H/W, S/W 
requirements, and creating BOM 
and samples 

2-4 

Validation 

Checking samples fulfil 
formalised requirements 

1-2 

Production 

Building and shipping customised 
products 

1 

TOTAL 


6-9 


Table 1 


Where only customised software components are required, the 

5 human resources required are likely to be in the range of *6' . 

Where both customised hardware and software are required, the 

human resources required are likely to be in the range of A 9'. 

The resources indicated for production in Table 1 above only 
10 include human resources required for ensuring all the required 
information for the building and shipping of the customised 
product is provided to the factory line, etc. It does not 
include the actual resources required for the building and 
shipping of the product. 

15 

As will be appreciated by those skilled in the art, the need 
for such high resources adds significantly to the overheads of 
the manufacturer, which in turn must be passed on to the 
customer in terms of the price of the product. 


20 


There is therefore a need for improving the method and process 
of managing and controlling a product build to alleviate the 
above mentioned problems and disadvantages. 


Statement of Invention 

In accordance with a first aspect of the present invention, 
there is provided a system for customising an electronic 
product, as claimed in Claim 1. 


In accordance with a second aspect of the present invention, 
there is provided a method of manufacturing customised 
products, as claimed in Claim 11. 


Further aspects and advantageous features of the present 
invention are as described in the appended Claims e 


Brief Description of the Drawings 


FIG. 1 is a simplified illustration of a known manufacturer/ 
supplier process for building a product based on received 
customer requirements 


Exemplary embodiments of the present invention will now be 
described, by way of example only, with reference to the 
accompanying drawings, in which: 
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FIG. 2 illustrates a requirements capture tool of a 
substantially automated control system for managing and 
controlling the production of a customisable product according 
5 to one embodiment of the present invention; 

FIG. 3 illustrates a process of generating a product using 
"building blocks" to represent the hardware and software 
domains, according to one embodiment of the present invention; 

10 

FIG. 4 is a simplified illustration of 
supplier process for producing a product 
received customer requirements, according to 
the present invention; and 

15 

FIG. 5 illustrates an exemplary embodiment of an 
implementation of the requirements capture tool of FIG. 2. 

Description of Embodiments of the Invention 

20 

FIG. 2 illustrates a substantially automated control system 
200 for managing and controlling the production of a 
customisable product, and in particular a requirements capture 
tool, according to one embodiment of the present invention. 
25 Such a control system 200 may be used by a 
manufacturer/supplier of customisable products, for example 
mobile phone handsets. 

The control system 200 comprises a requirements capture tool 
30 210, which may be linked to a product generator 220. 


a manufacturer/ 
build based on 
one embodiment of 
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The requirements capture tool 210 captures customer 
requirements, for example the requirements that a mobile phone 
network operator may have for mobile phone handsets. Such 
5 customer requirements may include, by way of example only, 
software and application requirements, colour and other 
hardware requirements, billing and delivery requirements, etc. 

It is envisaged that the requirements capture tool 210 may 
10 comprise an Internet based front-end, whereby a customer is 
able to directly access the tool via the Internet. In this 
way, the customer is able to enter the requirements at their 
own convenience. This has the advantage that it is not 
necessary for a sales representative to be present whilst 
15 capturing the requirements of the customer. 

In an alternative embodiment, the requirements capture tool 
210 may comprise a proprietary software application located 
on, for example, the computer (e.g. a laptop style computer) 

20 of a sales representative of the manufacturer/ supplier 
organisation. In this way, the sales representative is able to 
visit the customer and enter the customer requirements with 
the customer present. This has the advantage of the sales 
representative being able to answer any questions that the 

25 customer might have, or clarify any options available to the 
customer, etc. in a real time manner. 

In a still further alternative embodiment, the requirements 
capture tool 210 may comprise a proprietary software 
30 application provided by the manufacturer/supplier to the 
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customer for inclusion on the customer's computer network. 
Thus, the application can be made available to appropriate 
personnel of the customer for ordering products as and when 
required. 

5 

Notably, the customer requirements are entered directly into 
the requirements capture tool 210. In this way, the customer 
requirements may be entered directly in the format of the 
manufacturer's/supplier's internal process flow, for example 
10 in the form of a customisation checklist (CCL) . In effect, the 
customer requirements are therefore formalised at the point of 
capture . 

As will be appreciated by a person skilled in the art, the use 
15 of the requirements capture tool 210 provides a number of 
advantages over the known processes. 

Firstly, because the customer requirements are entered 
directly in the format of the manufacturer's/supplier's 
20 internal process format, and preferably by the customer 
himself /herself , problems are overcome: 

(i) a sales representative receiving the requirements 
over a period of time and having to collate the 

25 requirements; 

(ii) a sales representative having to interpret the 
requirements received from the customer; and 

(iii) the interpreted requirements having to be 
formalised by the order desk 


30 
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Consequently, there is no subjectivity or human error on the 
part of the manufacturer/supplier that could be detrimental to 
the accuracy of the formalised requirements. 

5 Furthermore, since the customer requirements are directly 
entered into the format of the manufacturer's/supplier's 
internal process format, the time delay inherent in the old 
system for achieving this is removed. 

10 Once all the customer requirements have been entered, they may 
be "submitted" to the product generator 220. This can be 
achieved in any suitable manner. For example, in the case of 
the requirements capture tool 210 comprising an Internet-based 
front-end, the requirements capture tool 210 further comprises 

15 a back-end residing on a server. The back-end receives the 
submitted requirements information, and stores the captured 
information in a database, for example a structured query 
language (SQL) database. The information in the database is 
then made available to the product generator 220. 

20 

In an alternative embodiment, the back-end receives the 
submitted requirements information and creates a definition 
file containing the captured information. The definition file 
may be in any suitable format, for example an extended mark-up 
25 language (XML) based format or other proprietary/non- 
proprietary format. This format can then be sent, or made 
available in a file storage area, to the product generator 
220. 
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On receiving the captured customer requirements information, 
the product generator 220 generates the necessary components 
to build a product, in accordance with the customer 
requirements. Such components, in particular, include, but 
5 are not limited to, software binary "images" etc. For 
physical components, such as hardware, etc., the required 
components are identified so that they can be allocated from 
stock . 

10 All parts and components of the product may have a unique part 
number. These part numbers are used to create a bill of 
material (BOM) . The BOM may be generated by the product 
generator 220, or alternatively by an Enterprise Resource 
Planning (ERP) System 230. 

15 | 

Having generated the necessary components, the product 
generator 220 makes the components available to a production 
system 240. For example, software components may be made 
available by storing them in a file storage area. The 
20 production system 240 is then able to use the generated 
components to build and ship the customised product. 

In one embodiment of the present invention, prior to the 
necessary components being made available to the product 
25 generator 220, the software components may be tested to ensure 
that they function as intended/required. 

The product generator 220 may generate these test scripts, 
which are based on the software components. Alternatively, a 
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separate tool (not shown) may generate the test scripts based 
on the customer requirements. 

The software components and the test scripts can then be 
5 provided to a device emulator (not shown) , which emulates a 
device onto which the software components are to be loaded. 
The test scripts are then run on the emulator to ensure that 
the software behaves as it should. 

10 The control system 200 further comprises an enterprise 
resource planning (ERP) system 230. The ERP system 230 may be 
coupled to each of: the requirements capture tool 210, the 
product generator 220 and the production system 240. 

15 An example of a suitable ERP system is SAP™, details of which 
can be obtained from www. sap. com . 

In an enhanced embodiment of the present invention it is 
envisaged that the requirements capture tool 210 provides for 
20 different types of user, such as customers, consumers and 
internal users (e.g. employees of the manufacturer/supplier 
organisation) . 

For example, customers, such as Network Operators, might have 
25 an on going relationship with the manufacturer/supplier. In 
this manner, the customer and the manufacturer/supplier would 
have typically previously negotiated certain terms, such as 
pricing, certain settings, graphics and logos, minimum 
quantities and other standard requirements that the customer 
30 might have. This information may be held within the ERP 
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system 230. When the customer logs onto the system (for 
example by way of entering a unique username and/or password) , 
the previously agreed details can automatically be retrieved 
from the ERP system 230, thus saving the need for the customer 
5 to re-enter such details each time they use the system. 

Consumers, on the other hand, will in general only make one 
off purchases. Therefore, they will not have negotiated 
requirements, etc. with the manufacturer/supplier. Therefore, 

10 it will be necessary for a consumer to enter all requirements. 
However, a consumer may be provided with fewer customisation 
options, since certain options may require either a particular 
level of technical understanding, or a minimum quantity 
purchased to make those options financially viable. 

15 Furthermore, consumers may be limited to maximum quantities, 
as a consumer is likely to have a lower ^credit rating' than, 
say, a network operator. 

Internal users may be provided with discounted prices, for 
20 example as part of an employee benefit package. 
Alternatively, internal users may be able to make use of the 
system for ordering samples which may be required for trade 
shows, to show to prospective new customers, or simply to test 
new products. 

25 

The ERP system 230 may also hold information regarding stock 
levels, lead times for ordering new stock etc., for example as 
provided by the production system 240. Furthermore, the ERP 
system 230 may also monitor production orders already 
30 scheduled on the production system 240. In this way, it is 
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possible to determine the earliest possible delivery dates for 
products depending on the requirements entered by a user of 
the system, based on availability of stock and when the 
product can be scheduled to be built. Consequently, a user 
5 can be provided with an estimated delivery date, or be able to 
select a favourable delivery date from a range of possible 
delivery dates. 

As previously mentioned, the product generator 220, on 
10 receiving the customer requirements, generates (or identifies) 
the necessary components for the customised product to be 
built . 

i 

From the point of view of software components, the product 
15 generator 220 generates, for example, software binary "images" 
containing the required features/ functionality/ applications, 
etc . 

From the point of view of hardware, it is envisaged that a 
20 user's requirements may include the selection of possible 
hardware options. For example, where the product is a mobile 
phone handset, the user of the system may be able to select 
the base model, the colour of the handset, the type of camera 
(e.g. the resolution/number of pixels), etc. Where this is 
25 the case, it is not necessary for the product generator 220 to 
generate any components . Instead, the relevant part numbers 
for the selected hardware components are simply included in 
the BOM, as mentioned above. 
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However, it is also envisaged that a user's requirements may 
include hardware options that are not necessarily considered 
as ^standard' . For example, a mobile phone network operator 
may specify that their logo or some other graphic be present 
5 on, for example, the bezel of the handset. Where this is the 
case, the product generator 220 generates a print template, or 
other appropriate guide/specification, which may automatically 
be sent to the supplier of, in this example, the handset 
bezels, along with the required quantity of bezels. 

10 Alternatively, the print template, or other appropriate 
guide/specification, may already exist, for example from a 
previously placed order or from prior negotiation, and stored 
in the ERP system 230. In this case, the product generator 
simply retrieves the print template or other appropriate 

15 guide/specification from the ERP system 230, and the required 
bezel (s), comprising the Network Operator logo, is/are 
automatically ordered from the relevant supplier. 

It is envisaged that this approach may also apply to 
20 packaging, manuals, marketing/advertising material, etc. 

As also mentioned above, every component of a product is 
allocated a unique part number. All part numbers are held and 
controlled in the ERP system 230. The product generator 220 
25 creates a complete list of all components that can be used in 
a product. 

In one embodiment of the present invention, the product 
generator will then pass the list to the ERP system 230, which 
30 for the known or previously used/generated components 


- 18 - 


retrieves the relevant part numbers. For new (i.e. 
specifically generated) components, the ERP system 230 may 
create new part numbers. 

5 The ERP system 230 then uses the part numbers to create the 
BOM for that product, which it stores and also passes back to 
the product generator 220. The product generator 220 is then 
able to make the components and their part numbers available 
to the production system 240. 

10 

In an alternative embodiment of the present invention, the 
product generator 220 retrieves the part numbers for the known 
or previously used/generated components from the ERP system 
230. For the new (i.e. specifically generated) components, the 

15 product generator 220 creates the new part numbers. The 
product generator 220 is then able to create the BOM itself, 
which it passes to the ERP system 230 for storing, along with 
the newly created part numbers. The product generator 220 is 
then able to make the components and their part numbers 

20 available to the production system. 

The production system 240 is provided with the BOM, 
identifying all required components, along with the quantity 
of units to be built and the delivery information. From the 

25 BOM, the production system 240 is able to generate a "pick 
list" or the like, which lists all the physical components 
(e.g. hardware, accessories, user manuals, packaging, etc.) 
required to build the product, and the quantities required to 
fulfil the order. This pick list can then be used to retrieve 

30 all necessary physical parts from stock. 
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Furthermore, the production system 240 is able to identify 
from the BOM all necessary software files (e.g. binary images, 
resource files etc.), which will have previously been made 
5 available by the product generator 220. The production system 
240 is then able to retrieve the required software files, and 
configure the assembly line for downloading the files into the 
units as they are built. 

10 A user of the system is, in effect, placing an order each time 
they submit their requirements. In one embodiment, the ERP 
system 230 tracks the progress of each order. Furthermore, it 
is envisaged that the ERP system 230 effectively controls the 
process, allowing each order to progress through each stage, 

15 or restricting orders from progressing if required. 

For example, when an order is placed (i.e. a user submits 
their requirements) , the requirements capture tool 210 sends 
the customer requirements to the product generator 220, as 
20 well as informing the ERP system 230 of the placing of an 
order. The product generator 220 waits until it receives 
confirmation from the ERP system 230 before generating the 
required components. 

25 Alternatively, on receiving the customer requirements from the 
requirements capture tool 210, the product generator 220 
notifies the ERP system 230 of the receipt of an order, and 
awaits confirmation to proceed from the ERP system 230 before 
generating the required components. 


30 
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On receiving the notification from the requirements capture 
tool 210, the ERP system 230 performs a check to ensure that 
it is acceptable to process an order from that particular 
user. For example, where the user is a customer such as a 
5 Network Operator, each customer may be awarded a credit limit. 
The ERP system 230 checks the current credit level for that 
customer, and if the customer is within their limit, the ERP 
system 230 will inform the product generator 220 to proceed 
with generating the required components. 

10 

Alternatively, the ERP system may contain, or have access to, 
a list of customers who have outstanding unpaid invoices, or 
the like. If the user is on this list, the ERP system 230 may 
then automatically send a notice (for example by email) to the 
15 user informing them that until the outstanding invoices have 
been paid no more orders will be accepted. The order may then 
be "held" until the outstanding invoices are paid, or the 
order is cancelled. 

20 Alternatively, it may be that payment for an order is due 
prior to an order being fulfilled. In this case, the ERP 
system 230 may await confirmation that a payment has been 
received before instructing the product generator 220 to 
proceed with generating the required components. 

25 

In this manner, the product generator 220 only generates 
required components for valid orders, with the ERP system 230 
performing certain checks prior to committing to the product 
build. This offers the advantage that computing resources and 
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the like are not wasted on generating components for orders 
that are not fulfilled. 

The ERP system 230 may also control the scheduling of product 
5 builds. For example, the ERP system 230 may monitor stock 
levels, and allocate stock to specific orders. When all 
components for a particular product order are available, the 
ERP system 230 schedules, or causes to be scheduled, the 
building of the product order with the production system 240. 

10 

In this manner, it is possible to cancel any order, for 
example if parts become unavailable or a customer wishes to 
cancel the order, with minimum interference to the production 
system 240. This allows the production system 240 to operate 
15 as efficiently as possible, and thereby aids in achieving 
maximum productivity on the assembly lines, etc. This is 
important since any confusion or delays that might occur on an 
assembly line or the like can result in significant drops in 
productivity and lost revenue. 

20 

Once a product has been built and shipped, the production 
system 240 may confirm shipment to the ERP system 230. 

The ERP system 230 may also contain pricing information for 
25 each product /order , which may be provided by the requirements 
capture tool 210 or product generator upon submission of the 
customer requirements (since the user may have been informed 
of the price prior to submitting the order) . 
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Alternatively, the ERP system 230 may calculate the price from 
the BOM. This can be achieved simply by associating each part 
number with a price. In this manner, the ERP system 230 may 
simply add up all the individual part prices to obtain the 
5 overall price for the product. 

Where new components are generated, at the time of assigning 
new part numbers, the price for each new component may be 
determined based on the contents of each component, or may be 
10 based on the price of alternative similar components. 

In either event, the ERP system 230 is configured to possess 
both the price (per unit) and the quantity of units shipped. 
Consequently, the ERP system 230 is able, upon confirmation of 
15 shipment, to automatically generate, or cause to be generated, 
invoices etc., as appropriate. 

Referring now to FIG. 3, the process of generating a product 
uses "building blocks" to represent the hardware and software 

20 domains. In particular, in the context of the present 
invention, embedded software elements of the product are 
represented as software building blocks. Embedded software 
elements, in the context of the present invention, comprise 
software modules where software-based functions of an 

25 electronic product, such as a mobile phone, are separated into 
code and data (i.e. software that is not ^executed' by a 
processor) . Thus, a tool is provided that allows 

configuration to be performed in a well-defined, automated 
manner. Notably, the configuration is performed safely (i.e. 

30 inconsistencies between software modules are avoided) . This 
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is advantageous when configuring complex embedded software- 
based products, due to the huge number of product variations 
that can be ultimately manufactured. Thus, a standardised 
process of driving down customisation throughout the embedded 
5 software contained within a product is supported. 


In this manner, the requirements capture tool 210 is able to 
provide a user (e.g. a customer, sales representative, etc.) 
with the opportunity to effectively "click" together a working 

10 device from, say, a mixture of embedded software and 
additional hardware components. The embedded software is such 
that a user "clicks" together a working software domain 
(hereinafter referred to as "image") comprising, for example, 
an OS and/or one or more applications and/or one or more 

15 settings and/or one or more resources to fit that phone. 


Notably, it is within the contemplation of the present 
invention that the customisation of a software-based 
electronic product may encompass every aspect of the product, 
20 in addition to the embedded software elements. 


Thus, in the context of the present invention, it is envisaged 
that the embedded software may be configured to represent 
further elements in addition to the software elements, for 
25 example representing: 


(i) One or more hardware elements; and/or 

(ii) One or more packaging elements; and/or 

(iii) One or more accessories. 


30 


- 24 - 


As such, it is envisaged that the customisation of the 
sof tware-baseci electronic product may encompass the box that 
the product is shipped in, for example, its size, shape, 
colour, logo affixed to the box or the product, any manuals 
5 that accompany the product, options for accessories, such as 
cables, battery chargers, replacement batteries, etc. for a 
phone product. 

Referring to FIG. 3, one implementation of the system 
10 architecture 300, arranged to control the complete 
configuration process for, say, the build of a Smartphone, 
Featurephone or similar complex wireless communication unit, 
is illustrated in more detail. The system architecture 300 
comprises a version-controlled file storage function 305, 
15 which for one embodiment of the present invention forms a part 
of the ERP system 230 of FIG 2. 

The version-controlled file storage function 305 comprises the 
necessary software and hardware building block definition 

20 files 310, core building blocks 315, variant builds 320, 
localisation files 325 and binary definition files 330, 335. 
In one embodiment of the present invention, the version- 
controlled file storage function 305 comprises, say, hundreds 
or thousands of software and/or hardware building blocks. 

25 Each block may also be provided with its own unique part 
number . 

The version-controlled file storage function 305 is operably 
coupled to the requirements capture tool 210 and the 
30 product/image generator 220. A customer may access a user 
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interface, such as a graphical UI (GUI) (not shown), of the 
requirements capture tool 210. When ^building' a graphical 
representation of the electronic product, the requirements 
capture tool 210 accesses representations of the embedded 
5 software, and preferably hardware building blocks, stored in 
the version-controlled file storage function 205. 

The output of the requirements capture tool 210 may comprise a 
"definition" file 345 containing all of the customer 

10 requirements. The definition file 345 of the device (that 
includes both hardware and software components, packaging and 
accessory components, billing and delivery information, etc.) 
may comprise all information regarding the device, at all 
levels. This file could, in theory, be regarded as the 

15 "recipe" for the construction of the device. The definition 
file 345 may take any suitable form, for example the 
definition file 345 may be in the form of a mark up language 
file, such as an adaptation of XML. 

20 Since the user (e.g. the customer) has defined the device's 
requirements, including in one embodiment its look and feel, 
it is possible to generate a set of scripts for use by a test 
(harness) engine (not shown) ; to ensure that the end product 
produced matches the customer requirements as provided 

25 directly by the customer. 

In combination with the assembly database (validation) , this 
dramatically reduces the requirements for test and delivery of 
a product to a customer. Furthermore, because the 

30 subjectivity and human error factors inherent in the known 
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process have been substantially removed, the testing is 
performed directly against the customer requirements. This 
significantly improves the quality (from the customer's point 
of view) of the delivered product. 

5 

The definition file 345 is passed from the requirements 
capture tool 210 to the product generator 220. The product 
generator 220 uses the information contained within the 
definition file to generate a set of software image components 
10 to be loaded onto a device. These components are to be issued 
unique part numbers, and are included, along with the part 
numbers of all other components of the device, into a bill of 
material (BOM) 360. 

15 The BOM 360 is then passed to a production system, for example 
the production system 240 of FIG. 2, for actual construction 
of the product on the assembly line. 

The production system 240 may comprise a configuration 
20 administrative system automatic software loader 375, for 
configuring the product with selected software elements, such 
as mobile phone applications. The selected software code/ 
applications are extracted from a configuration system 
database 380. 

25 

For the purpose of configuring a build of a wireless 
communication unit such as a Smartphone or Featurephone, it is 
envisaged that the product/image generator 220 may generate a 
production order with an adapted BOM 360. In an enhanced 
30 embodiment of the present invention, the adapted BOM may be 
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used to emulate in software the operation of the wireless 
communication unit, for example, to be run on a real-life 
phone or on a PC 365. Again, the aforementioned test scripts 
can again be used to provide a test environment for the 
5 product at a virtual stage, before committing build resource. 


Advantageously, with the provision of an emulator according to 
the enhanced embodiment of the present invention, the solution 
may be iterative, i.e. a customer or consumer is able to 

10 assess the various selectable hardware and/or software options 
from the version-controlled file storage 305. Furthermore, 
the customer or consumer may be able to assess the impact in a 
real-life scenario, in a real-time manner, as more software 
elements are incorporated into the emulated phone. Thus, an 

15 iterative solution may be used to ensure consistency across 
various software/hardware versions. 


Advantageously, this virtual device may also be presented 
during creation and configuration, so that a user can 
20 visualise and interact with a virtual representation of their 
product . 


It is envisaged that the BOM 360 may also comprise a list of 
parts, with new additional information relating to a 
25 particular product build. In one embodiment, the BOM 360 may 
also comprise a favourite list of selectable hardware and/or 
software elements contained, say, in a browser. 


A further advantage of the inventive concept hereinbefore 
30 described is that it is far easier for manufacturers and 
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customers to collaborate on joint development work. In 
particular, the implementation may be web-based, to allow, for 
example, a wireless communication unit manufacturer to work 
with customers/ vendors in an on-line manner. 

5 

In addition, it is envisaged that the aforementioned 
arrangement may be used as part of various project management 
exercises, in the development of products. That is, in this 
manner, a development or project engineer or manager is able 
10 to validate the inter-working of particular software and (in 
one embodiment) hardware components more easily during a 
development phase of the product. 


The variant builds 320 may contain order/customer specific 
15 information and comprise the configurable software items for 
the wireless communication unit. Thus, the product generator 
220 is used by the customer to combine software and/or 
hardware building block representations, based on the core 
building blocks 315, and one or more variant builds 320, 
20 localisation files 325 and binary definition files 330, 335. 
In one embodiment, the product generator 220 also specifies 
the version of the build environment that is to be used/being 
used . 


25 The requirements capture tool 210 may also provide an object 
representation of configurable elements in the build 
environment. As such, in one embodiment of the present 
invention, the requirements capture tool 210 comprises 
software and hardware representations of product elements, 

30 such as mobile phone elements. In an enhanced embodiment of 
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the present invention, the software representation comprises 
embedded software elements, so that a mobile phone can be 
designed/ built from these embedded software elements. In one 
embodiment of the present invention, the embedded software 
5 elements are stand-alone items that may be configured within a 
phone in a A plug-in' type manner. 

As previously mentioned, it is envisaged that the software 
build can be performed over the Internet, through a client 

10 application or by another system or via a customer's system. 
Furthermore, it is envisaged that a new application can be 
added as an option on the requirements capture tool 210, as a 
new isolated module (for example in the form of a Java bean) 
that describes both the application and its configuration 

15 relevant behaviour. In this form, the customer or consumer is 
able to manipulate the requirements capture tool 210 elements, 
in effect by performing a drag and drop and verify operations. 
The build environment/product generator 220 is modified to 
deal with the application object, which may not require 

20 extensions and/or modifications to many, if any, different 
parts of the build environment. 

A hardware or software component object in the requirements 
capture tool 210 may be an object in the build environment. 
25 If the software component object is not the same as the object 
in the build environment, then the match should be as close as 
possible . 

An example software candidate for representing these embedded 
30 software elements is C++ or JAVA. The classes of configurable 
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elements may be equipped with a subset of the behaviour 
methods of matching Java beans in the requirements capture 
tool 210, as will be appreciated by a skilled artisan. It is 
envisaged that a JAVA based arrangement provides the simplest 
5 and most efficient mechanism to implement a x drag and drop' 
function within the requirements capture tool 210, 

In addition, it is envisaged that other advantageous methods 
may be supported using C++ classes, which are particularly 
10 applicable in a build environment. It is also envisaged that 
the classes in the build environment may comprise additional 
levels that are built into the software to handle more detail- 
specific builds. 

15 A listing of various software configurable (selectable) 
elements, as used in the one embodiment of the present 
invention, comprises : 


(i) Customer variant - Contains customer specific 
20 Bitmaps, splash screens, ring tones, etc.; 

(ii) Customer Applications variant - Contains customer 
specific applications; 

(iii) Language variant - Contains a set of languages 
with a specified default language; and 

25 (iv) Specific applications, logos, bitmaps, splash 

screens, ring tones, etc. 


Furthermore, it is envisaged that a listing of various 
hardware configurable elements, as used in one embodiment of 
30 the present invention, comprises: 
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(i) 


Battery type; 


(ii) 


Bezel; 


(iii) 


Labels; and 


5 


(iv) 


Accessories . 


A skilled artisan will appreciate that many other variant 
/selectable elements may be offered in alternative 
applications . 


Downloading of binary files to a wireless communication unit 
build may be performed using a universal serial bus (USB) 
connection, or by use of a removal memory module (such as a 
memory card) , which is used for conventional programming of 
15 mobile phones or direct programming at the point of assembly 
or configuration. 

Although embodiments of the present invention have so far been 
described as allowing either a customer or a sales 

20 representative being able to utilise the features and 
functionality of the present invention, it is contemplated 
that the requirements capture tool may also be made available 
to consumers. In this way, a consumer is able to order a 
customised single unit to their requirements. Alternatively, 

25 it is envisaged that a consumer may be able to select/ 
configure software upgrades, additional software applications, 
accessories, etc. for a previously purchased product. 

In accordance with one embodiment of the present invention, an 
30 input for the requirements capture tool 210 may be a 


10 
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Customisation Checklist, as completed by the customer or 
consumer. Customisation of a wireless communication unit, as 
specified by the customer or consumer, may require changes to 
a device configuration, depending upon, say, a rules database 
5 (not shown) for the requirements capture tool 210. For 
instance, the consumer or customer may be provided with the 
opportunity to specify a combination of two applications where 
the rules database specifies that these applications typically 
cannot be used together, for example due to incompatibilities 
10 between the two applications. This means that the customer 
will have to change his/her requirements. 


One embodiment of the present invention envisages that the 
customer is provided with the ability to specify several 
15 ^application' items of the user interface of the wireless 
communication unit, which may be configured/ arranged to be 
customisable, by the end user. Examples of these items 
comprise : 


20 (i) Background bitmaps; 

(ii) Colour schemes; 

(iii) Sounds; 

(iv) Animations; 

(v) Fonts; and 

25 (vi) Indicators such as Key-lock, GPRS signal, etc, 


The customer may also be provided with an opportunity to 
specify his/her own splash screen, i.e. the initial screen 
that appears for a few seconds following start-up and shut- 
30 down, as well as specify how long the splash screen is to be 
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displayed. In addition, the customer may also be provided 
with an opportunity to specify one or more customer-specific 
ring tones to be loaded into the phone. 

It is envisaged that the customer may also be provided with an 
opportunity to specify items that are specific for use in a 
particular country or region, in relation to the 
manufacture/build of a particular order. For example, the 
customer may specify: 

<i) One or more languages, where the number of specified 

languages is limited by the amount of memory used by 
the total build; 

(ii) A default language, if more than one language is 
specified. Advantageously, this allows the Customer 
to order a single phone capable of operating in two 
different countries, where the phone starts up with 
the default language for the correct country in 
which the phone was sold; and 

(iii) Default regional settings to control, for example, a 
display of date and/or time in the correct format 
for the specified region, and/or a display of 
currency/numbers, etc. in a correct format for the 
specified region and/or a default time zone, etc. 

It is also envisaged that the customer is provided with the 
opportunity to define the connection settings for each phone 
from, say, a list of connection types that are supported by 
the phone, to match the customer's setup. Such connection 
settings may include one or more of the following: 


- 34 - 


(i) Wireless Access Protocol (WAP) parameters, where 
all WAP connection settings are specified in the 
WAP provisioning Content Specification, available 

5 from the WAP Forum ( http : / /www . wap forum .org ) ; 

(ii) General Packet Radio System (GPRS) parameters; 

(iii) Dial-up settings and parameters; 

(iv) Browser settings, including browser favourites. 
Here, the Customer may be provided with the 

10 opportunity to define a list of browser 

favourites to be pre-conf igured in the phone for 
a particular order. The definition of a browser 
favourite may include at least a descriptive tag 
and the URL. Additionally, the Customer may be 

15 able to specify a sequence in which the Browser 

favourites appear; 

(v) Proxy settings and parameters; and 

(vi) Over-the-air programming (OTAP) mechanisms. 

20 Advantageously, the aforementioned build mechanism enables the 
phone binaries to be built by someone who is not technically 
proficient, thereby enabling orders for the phone to be 
fulfilled in a customisable manner. 

25 Thus, a binary image may be generated in a post manufacturing 
process step in a distribution/retail context using a 
plurality of selectable software representation blocks 

In addition, it is possible for customer specific components 
30 to be incorporated, without the need for the customer to 
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manually specify them. For example, in the above example, the 
resource files of the product may include customer specific 
graphics and logos. Such logos may have been previously 
arranged and agreed with the customer, for example from 
5 previous orders and/or negotiations . 

In this manner, the order information may comprise a customer 
identifier for a particular software-package option. Thus, 
the part number for the software-package option may be 
10 specific to, say, Customer y X' . 

Alternatively, the customer may upload desired graphics and/or 
audio files at the point of capturing the customer 
requirements . 

15 

As previously mentioned, the order for an electronic product, 
particularly when placed by a customer such as a Network 
Operator, may encompass a large number of products. Sets of 
these products may be configured in substantially the same 
20 manner, or some may be configured with individual 
requirements . 

It is within the contemplation of the present invention that 
the inventive concepts hereinbefore described are not limited 
25 to the described wireless communication unit software build or 
associated manufacturing system of embodiments of the present 
invention. Indeed, it is envisaged that the inventive 

concepts are applicable to any suitable mass-produced 
software-based electronic product (or product that offers 
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software variants) comprising embedded software and hardware 
elements . 

Referring now to FIG . 5, there is illustrated an exemplary 
5 embodiment 500 of an implementation of the requirements 
capture tool 210 of FIG. 2. The requirements capture tool 210 
may comprise a front-end component and a back-end component. 

The front-end component is provided in the form of a website, 
10 which may be accessible to a customer 310 via the Internet 
520. The front-end component is hosted on a front-end server 
530 , which may be located within a de-militarised zone (DMZ) 
of the manufacturer's corporate computer network. 

15 For reference, a DMZ is middle ground between an 
organisation's trusted internal network, such as an intranet, 
and an un-trusted, external network such as the Internet. 
Another term for a DMZ is a "perimeter network". A DMZ is a 
sub-network that may sit between firewalls, or off one leg of 

20 a firewall. In the illustrated embodiment, the DMZ sits off 
one leg of a firewall 540 of the manufacturer's corporate 
computer network. 

The front-end component may be developed using ASP.NET. 

25 

For reference, ASP (or an Active Server Page) is a Web server 
technology that allows for the creation of dynamic, 
interactive sessions with a user. An ASP is a web page that 
contains hyper text mark-up language (HTML) and embedded 
30 programming code written in VBScript or Jscript. When an 
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internet information server (e.g. web server) encounters an 
ASP page requested by a browser, it executes the embedded 
program. ASP.NET is an enhanced version of ASP for the .NET 
platform. 

5 

The back-end component may be provided as a series of Java 
Servlet, provided via a Java web server /listener , and is 
hosted on a back-end server 550. The back-end server 550 may 
be located within a trusted part of the manufacturer's 
10 corporate computer network, such as a LAN. 

The requirements capture tool 210 may also comprise a database 
component, which may also be located on the back-end server 
550. 

15 

The database component holds the building block definition 
files etc. In an alternative embodiment to that illustrated 
in FIG. 3 where customised product definitions for the 
embodiment illustrated in FIG. 5 are provided to the product 
20 generator 220 in a "definition file", the customised product 
definitions are stored in the database component and the 
product generator 220 is able to access the product 
definitions when required. 

25 The database component may be in the form of an SQL database, 
since this provides manageability, quick access to stored 
data, flexibility and the ability to store not just 
information, but binary data (for example graphics/audio 
files) as well. 

30 
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By locating the back-end and database server 550 within the 
relatively secure environment of the LAN, the back-end 
component and database are afforded security. 

5 The location of the front-end component in the DMZ provides 
the advantage that it is accessible to customers, without 
allowing access to the more sensitive back-end component and 
database . 

10 As will be appreciated by a skilled artisan, when a customer 
accesses the requirements capture tool 210, the front-end 
component is loaded, in the form of a web page, from the 
front-end server 530. The front-end component then 
communicates with the back-end component. In order to achieve 

15 this, the method of communication is required to traverse the 
firewall restrictions . 

An advantage of implementing a web-based front-end is that 
firewalls in general allow hypertext transport protocol (HTTP) 

20 connections to transverse them. Consequently, by utilising a 
simple XML over HTTP based message system for communication 
between the front-end component and the back-end component, 
minimal (if any) changes are required to the firewall 
restrictions to implement the requirements capture tool 210. 

25 These HTTP based communications can be secured by simple 
conversion to HTTPS (secure HTTP) , allowing for all 
transactions between client and server to be encrypted. 
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An alternative communication protocol is SOAP (simple object 
access protocol) , which is a message-based protocol based on 
XML for accessing services on the Internet. 

5 Barring an initial handshake connection from the front-end 
component to the back-end component, the front-end system may 
be driven by the back-end component. 

The back-end component provides, for example via XML, the 
10 front-end component with a series of questions and potential 
answers, which the front-end component presents to the user. 
The back-end component may also provide certain validation 
criteria. In this way, answers provided by a user (i.e. the 
customer) will be subjected to an initial validation by the 
15 front-end component, and then returned to the back-end 
component . 

Each returning message is stamped with authentication 
credentials to identify the user etc. Such credentials may 
20 include, by way of example only, one or more of the following: 


(i) 


A timestamp; 


(ii) 


A username; 


(iii) 


An access level; 


25 


(iv) 


An ASP session ID; 


and 


(v) 


A Java session ID. 


30 


This implementation of the requirements capture tool 210 
enables the front-end to remain stateless and able to display 
a variety of options and questions without the need for 
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processing by the front-end component, or updating of the 
front-end component . 

On loading the front-end component, the customer may be 
5 required to ^log-in', or register. 

To log-in, the customer may enter a username and password. The 
front-end component then returns the entered username and 
password to the back-end component, which uses the username to 
10 determine whether an account exists by accessing data within 
the database component. If an account does exist for that 
username, the password is then compared with a password stored 
within the database component. 

15 If both the username and password are correct, the back-end 
component then may check to see if a customer record exists 
within the database to determine whether the account has been 
suspended. If the customer account has not been suspended, a 
user session is started, and main menu questions, valid 

20 answers and validation criteria are sent to the front-end 
component . 

To register, the customer enters required details, such as a 
username, password contact details, etc. Alternatively, a 
25 username and/or password may be automatically generated for 
the customer for security reasons. 

This information is then returned to the back-end component, 
which creates the new customer account within the database 
30 component. 
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In one embodiment of the present invention, the account is 
initially suspended in order for financial checks and the like 
to be carried out. The account can then be activated at a 
5 later time/date once the required checks have been carried 
out. The customer may, for example, be sent an email 
informing them when the account is activated, and also where 
appropriate with the automatically generated username and/or 
password . 

10 

Having successfully logged in, the customer may be provided 
with a menu of options, which in the case of a mobile 
telephone handset manufacturer may comprise one or more of the 
following: 

15 

(i) 
(ii) 
(iii) 
(iv) 

20 

On the customer selecting one of the options, the front-end 
component returns the selected option to the back-end 
component, which retrieves the next question (s), permitted 
answers, validation criteria, etc from the database component, 
25 depending upon the returned information. 

For example, where the customer chooses to configure a new 
handset, the subsequent message from the back-end component 
instructs the front-end component to ask the customer to 
30 select the country in which the handset is intended to be 


Configure new handset; 
Load saved configuration; 

Re-order previous handset configuration; and 
Logout . 
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sold. The message from the back-encl component may also 
include a list of countries from which the customer may 
choose . 

5 On receiving the selected country information from the front- 
end component, the back-end component retrieves a list of 
valid handset models for that particular country from the 
database, and returns this list to the front-end component 
along with the instruction for the customer to choose a 
10 handset model . 

It is within the contemplation of the present invention that 
the information provided to the front-end component also 
includes information relating to each handset model, and may 
15 also include graphical representations of each handset model. 
In this way the front-end component is able to display this 
information to the customer, aiding them in choosing the 
handset model they require. 

20 When the back-end component subsequently receives chosen 
handset information, it creates a handset session, including 
the default features, functionality, settings etc. for the 
selected handset model. 

25 The back-end component then continues to provide questions, 
etc. to the front-end component, and receive responses back 
from the front-end component, thereby allowing the customer to 
configure the handset. Each time the customer alters the 
configuration of the handset, the back-end component updates 

30 the handset session. 
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It is also contemplated that a customer is able to upload 
digital resources, such as graphics files and audio files, 
which are optional or required by the user to be included as 
5 part of the customised product. Furthermore, the back-end 
component provides the front-end component with validation 
criteria such as valid file formats, size of files, etc. In 
this way, the digital resources can be validated at the point 
of capture. 

10 

By capturing, and verifying, digital resources at the outset, 
delays, etc. that occur in known customisation mechanisms are 
substantially alleviated. Furthermore, by storing the digital 
resources in the database component or including them in the 
15 definition file, the digital resources are directly associated 
with orders/product definitions, thus substantially removing 
the problems of misplacing the digital resources or using the 
wrong digital resources. 

20 The customer may be able to save the handset session at any 
point. When the back-end component receives a request to save 
the session, it instructs the front-end component to request a 
reference from the customer. 

25 On receiving the reference from the front-end component, the 
back-end component checks to see if that reference already 
exists within the database for that customer. If not, the 
back-end component stores the handset session, including any 
digital resources provided by the customer, in the database 
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under the customer reference, and returns the front-end 
component to the main menu. 

In this way, a customer is able, for example from the main 
5 menu, to return to a previous handset session to continue 
configuring the handset, or to modify previous changes. 

When a customer wants to order (or re-order) a handset, if the 
appropriate handset session is not already open, the back-end 
10 component retrieves the appropriate handset session from the 
database, and instructs the front-end component to request 
delivery information and number of units required. 

On receiving the delivery information from the front-end 
15 component, the back-end component makes the handset 
configuration information in the database available to the 
product generator 220, and passes information on the delivery 
and number of units to the ERP system 230. The customised 
handset can then be produced to the desired specification. 

20 

FIG. 4 is a simplified illustration of a manufacturer /supplier 
process 400 for producing a product build based on received 
customer requirements according to one embodiment of the 
present invention . 

25 

As with the prior art process 100 illustrated in FIG. 1, the 
process 400, according to one embodiment of the present 
invention, begins with a customer (or other user of the system 
such as a consumer or employee of the manufacturer /supply 
30 organisation) determining their requirements, in step 410. 
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Next, the customer enters the requirements into the 
requirements capture tool 210, as illustrated in step 420. In 
one embodiment of the present invention, the requirements 
capture tool 210 is configured such that the requirements are 
5 entered directly into the format of the internal process flow 
of the manufacturer/supplier. 

As will be appreciated by a skilled artisan, by the customer 
requirements being entered directly into the requirements 
10 capture tool 210 by the customer, in the format of the 
internal process flow of the manufacturer /supplier , the 
subjectivity and human error on the part of the 
manufacturer/supplier that afflicts the prior art process 
illustrated in FIG. 1 is substantially alleviated. 

15 

Furthermore, it is not necessary for a sales representative to 
manually collate the customer requirements, nor for the 
interpreted requirements receive from a sales representative 
to be manually formalised. Consequently the inherent delays 
20 relating to these steps in the prior art process illustrated 
in FIG. 1 are substantially removed. 

In step 430, the requirements capture tool 210 captures the 
requirements provided by the customer, in step 430. In step 
25 440, the requirements capture tool 210 then makes the 
requirements available to the product generator 220. 

In step 450, the product generator 220 generates required 
software components and creates a Bill of Materials (BOM) . In 
30 an alternative embodiment, the BOM is created by an enterprise 
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resource planning system, such as the ERP system 230 of FIG. 
2, based on a list of components provided by the product 
generator 220. 

5 In step 460, the software components generated by the product 
generator 220 are tested using automated test scripts on a 
product emulator (not shown) . The test scripts may be 
automatically generated based on the captured requirements, 
and may be generated by the product generator 220 or by a 
10 separate test script generator. The criteria for the tests 
more accurately represent the requirements of the customer 
compared to the prior art process of FIG. 1, since the test 
scripts are based directly on the requirements provided by the 
customer . 

15 

The software components and test scripts may be automatically 
loaded into the emulator, and tested, to ensure that the 
software fulfils the customer requirements. 

20 Where the customer requirements only require customised 
^software' components, once the software components have been 
tested using the test scripts, no further testing or 
validation is required. Thus, the software components and the 
BOM, etc. can be made available to the production system 240. 

25 Thus, the next step 490 is simply for the product to be 
produced and shipped to the customer. 

From the point of view of the manufacturer's resources, i.e. 
actual people required to perform tasks etc. when only 
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customised software components are required; Table 2 below 
illustrates the required resources. 


Area 

Task 

Resources 

Capture tool 

Capturing customer requirements 

0 

Product Generator 

Generating required software 
components and BOM 

0 

Auto-test scripts 



Production 

Building and shipping customised 
products 

0 

TOTAL 


0 


5 Table 2 

The resources indicated for production in Table 2 above only 
include resources required for ensuring all the required 
information for the building and shipping of the customised 
10 product is provided to the factory line etc. It does not 
include the actual resources required for the building and 
shipping of the product. 

As can be seen, the present invention provides a system 
15 whereby it is possible for an order to be received (i.e. when 
a customer enters their requirements) and fully processed 
through to production without any human resources. In 
comparison, the prior art process of FIG. 1 requires around 
six human resources. 

20 

As will be appreciated by those skilled in the art, this 
reduction in resources significantly reduces the overheads of 
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the manufacturer, which in turn can be passed on as a saving 
to the customer in the price of the product. Alternatively, 
the reduction in overheads can free up finances that can be 
put into other areas of the business, such as research and 
5 development, etc. 

It is further envisioned that throughout the entire 
customisation and production process, customisation 
information, etc. is maintained in a substantially human 
10 readable form in order to facilitate tracking, maintenance and 
auditing . 

Referring back to FIG. 4, where customised hardware components 
are required, there are the additional steps of creating the 
15 required hardware components and samples in step 470 and 
checking the samples fulfil the customer requirements in step 
480. 

From the point of view of the manufacturer's resources, i.e. 
20 actual people required to perform tasks etc. when customised 
'software' and 'hardware' components are required; Table 3 
below illustrates the required resources. 


Area 

Task 

Resources 

Capture tool 

Capturing customer requirements 

0 

Product Generator 

Generating required software 
components and BOM 

0 

Auto-test scripts 



Manufacturing/ 

Implementing H/W requirements, 

2 
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Development 

and creating samples 


Validation 

Checking samples fulfil customer 
requirements 

1 

Production 

Building and shipping customised 
products 

0 

TOTAL 


3 


Table 3 

The resources indicated for production in Table 3 above only 
5 include resources required for ensuring that all of the 
required information for the building and shipping of the 
customised product is provided to the factory line, etc. It 
does not include the actual resources required for the 
building and shipping of the product. 

10 

As can be seen, the present invention provides a system 
whereby it is possible for an order to be received (i.e. when 
a customer enters their requirements) and fully processed 
through to production with only *3' human resources required. 
15 In comparison, the known process of FIG. 1 requires around A 9' 
human resources. 

Once again, this reduction in resources significantly reduces 
the overheads of the manufacturer, which in turn can be passed 
20 on as a saving to the customer in the price of the product. 
Alternatively, the reduction in overheads can free up finances 
that can be put into other areas of the business, such as 
research and development, etc. 
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In practice, it is likely that the manufacturer /supplier 
organisation will require an additional resource to maintain a 
system according to the present invention, for example the 
control system 200 for managing and controlling the production 
5 of a customisable product. However, even with this additional 
resource, the overall resources required are significantly 
less than that required by known processes. 

It will be understood that the control system, as described 
10 above, tends to provide one or more of the following 
advantages : 

(i) Removes delay in the processing of orders for 
customised products; 
15 (ii) Reduces subjectivity and human error in capturing 

and fulfilling customer requirements; 

(iii) Reduces the amount of resources required in 
processing orders for customised products, resulting in: 

a) Economic savings; and/or 
20 b) Freeing up resources for other tasks 

(iv) Facilitates the ordering of new products from a 
customer's/consumer's point of view, thereby improving 
saleability of products; 

(v) Allows a simple and effective way of employees of 
25 the manufacturer/supplier organisation to obtain products for: 

a) Personal use (for example as part of an 
employee benefit scheme) 

b) Samples to show to prospective customers or at 
a trade show, etc. 
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(vi) Provides a repeatable, and therefore controllable 
process, which allows for improved quality control, which in 
turn allows for: 

a) Manufacture of higher quality products; and 
5 b) Customer confidence; 

(vii) Provides a means for uploading, and validating at 
the point of capture, digital resources such as graphics and 
audio files; and 

(viii) Provides a means for validating requirements, or 
10 at least only allowing valid requirements, at the point of 

capture . 

Overall, the present invention provides a system that 
facilitates a more efficient and effective method of 
15 implementing a manufacturing-based business, and can form an 
integral part of the running of a business. 

Whilst embodiments of the present invention are described 
above, it is clear that one skilled in the art could readily 
20 apply variations and modifications of such inventive concepts. 

Thus, an improved control system for managing and controlling 
the production of a customisable product and method therefor 
has been described where at least one of the aforementioned 
25 disadvantages with prior art arrangements has been alleviated. 
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Claims 

1. a system (200, 500) for customising an electronic 
product (200) comprising: 

5 a customer requirements capture tool (210) arranged to 

receive a customer's requirements electronically and display a 
plurality of customisation options to a customer; 

a back-end processing function (550), operably coupled 
to the customer requirements capture tool (210) and arranged 

10 to control the plurality of customisation options displayed to 
the customer and process inputs entered onto the customer 
requirements capture tool (210), wherein the back-end 
processing function captures one or more digital resources 
selected by the customer and, in response thereto, arranges 

15 the customer requirements capture tool (210) to display said 
one or more digital resources to the customer in enabling the 
customer to customise the electronic product. 

2. A system (200, 500) for customising an electronic 
20 product (200) according to Claim 1, wherein the system further 

comprises a database operably coupled to the back-end 
processing function for storing the one or more digital 
resources, such that the selected one or more digital 
resources are directly associated with a customised electronic 
25 product . 

3. a system (200, 500) for customising an electronic 
product (200) according to Claim 1 or Claim 2, wherein the 
system further comprises a verifying function for verifying 
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one or more digital resources upon selection by the customer's 
requirements electronically. 

4. a system (200, 500) for customising an electronic 

5 product (200) according to Claim 3 further characterised in 
that the verifying function generates one or more test scripts 
for testing an electronic version of the electronic product in 
response to the selected customer's requirements. 

10 5. A system (200, 500) for customising an electronic 

product (200) according to any preceding Claim further 
characterised in that the back-end processing function 
performs a customer authentication check to validate the 
customer electronically entering the customer requirements. 

15 

6. A system (200, 500) for customising an electronic 
product (200) according to Claim 5 further characterised in 
that following each option selection by a customer, the back- 
end processing function returns a message comprising an 

20 authentication validation to identify the selection made by 
the customer. 

7. a system (200, 500) for customising an electronic 
product (200) according to Claim 6 further characterised in 

25 that the authentication check includes providing one or more 
of the following within the message: 

(i) A timestamp; 

(ii) A username; 

(iii) Access level; 

30 (iv) ASP session ID; and/or 
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(v) Java session ID. 

8. A system (200, 500) for customising an electronic 
product (200) according to Claim 8 further characterised in 

5 that the back-end processing function provides a sub-selection 
of options to the customer requirements capture tool (210) in 
response to validating an access right of the customer. 

9. A system (200, 500) for customising an electronic 
10 product (200) according to any preceding Claim further 

characterised in that the customer requirements capture tool 
(210) is a web-based user interface. 

10. A system (200, 500) for customising an electronic 
15 product (200) according to any preceding Claim further 

characterised in that the back-end processing function updates 
an image displayed to the customer via the customer 
requirements capture tool (210) in response to a number of 
electronic entries of the customer requirements. 

20 

11. A method (400) for customising an electronic product 
(200) comprising the steps of: 

receiving, by a customer requirements capture tool 
(210), a customer's requirements electronically; 
25 displaying a plurality of customisation options to a 

customer; 

processing customer requirements by a back-end 
processing function, operably coupled to the customer 
requirements capture tool (210); 
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capturing (430) one or more digital resources by the 
back-end processing function as selected by the customer and, 

displaying said one or more digital resources to the 
customer, in response thereto, to enable the customer to 
5 customise the electronic product. 

12. The method for customising an electronic product (200) 
according to Claim 11, wherein the method further comprises 
the step of: 

10 storing the one or more digital resources, such that 

the selected one or more digital resources are directly 
associated with a customised electronic product. 

13. The method for customising an electronic product (200) 
15 according to Claim 11 or Claim 12, wherein the method further 

comprises the step of verifying one or more digital resources 
upon selection by the customer's requirements electronically. 

14. A method for customising an electronic product (200) 
20 according to Claim 13 further characterised in that the step 

of verifying comprises the step of: 

generating one or more test scripts for testing an 
electronic version of the electronic product in response to 
the selected customer's requirements. 

25 

15. A method for customising an electronic product (200) 
according to any of preceding Claims 11 to 14 further 
comprising the step of authenticating a customer entering the 
customer' s requirements electronically. 

30 
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10 


15 


16. A method for customising an electronic product (200) 
according to Claim 15 further characterised in that the 
authentication validation includes one or more of the 
following : 

(vi) A timestamp; 

(vii) A username; 

(viii) Access level; 

(ix) ASP session ID; and/or 

(x) Java session ID. 

17. A method for customising an electronic product (200) 
according to Claim 15 or Claim 16 further characterised by the 
step of: 

providing a sub-selection of options to the customer 
requirements capture tool (210) in response to validating an 
access right of the customer. 


18. A method for customising an electronic product (200) 

according to any of preceding Claims 11 to 17 further 
20 characterised by the step of: 

updating an image displayed to the customer via the 
customer requirements capture tool (210) in response to a 
number of electronic entries of the customer requirements. 
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ABSTRACTED-PUB-NO: GB 2434223 A 
BASIC-ABSTRACT: 

NOVELTY - The system has a capture tool arranged to receive a customer's 
requirements electronically ad display customization options to a customer, 
and a back-end processing function coupled to the capture tool and arranged 
to controls the customization options displayed to the customer and process 
inputs entered into the capture tool. The back-end processing function 
captures one or more digital resources selected by the customer, and 
arranges the capture tool to display digital resources to the customer 
enabling the customer to customize electronic product. 

DESCRIPTION - An INDEPENDENT CLAIM is also included for a 
method for customizing electronic product. 

USE - For customizing electronic product by providing manufacturer's user 
interface to support the customization in which a customer is provided with 
the ability to completely specify their requirements for the design, 
construction and delivery of the product. 

ADVANTAGE - Firewalls allow hypertext transport protocol (HTTP) 
connections to traverse them, consequently, by utilizing a simple extended 
markup language (XML) over HTTP based message system for 
communication between the front-end component and the back-end 
component, minimal, if any, changes are required to the firewall restrictions 
to implement the requirements capture tool. HTTP based communication 
can be secured by simple conversion to secure HTTP, allowing for all 
transactions between client and server to be encrypted. Eliminates 
subjectivity or human error on the part of the manufacturer/supplier that 
could be detrimental to the accuracy of the formalized requirements. 
Removes the time delay inherent in the old system since the customer 
requirements are directly entered into the format of the manufacturer's/ 
supplier's internal process format. Saves the need for the customer to re- 
enter such details each time they use the system since the previously agreed 
details can automatically be retrieved from the enterprise resource planning 
(ERP) system when the customer logs onto the system. Computing 
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resources and the like are not wasted on generating components for orders 
are not fulfilled. Allows the production system to operate as efficiently as 
possible, and thereby aids in achieving maximum productivity on the 
assembly lines. 

DESCRIPTION OF DRAWING(S) - The figure shows the simplified 
illustration of a manufacturer/supplier process for producing a product build 
based on received customer requirements. 
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